><<A lot of the anti-goto sentiment comes out of Wirth's article "GOTO
>considered harmful,...>>
>
>As one polite person pointed out to me by email, the paper "GOTO
>Considered Harmful" was written be Edsger Dijkstra, not Niklaus Wirth. I
>always get them confused--they both have unpronouncable last names. I
>believe Dijkstra's paper appeared in the CACM, but I don't have it.
>From Jargon File 3.0.0:
:considered harmful: adj. Edsger W. Dijkstra's note in the
March 1968 "Communications of the ACM", "Goto Statement
Considered Harmful", fired the first salvo in the structured
programming wars. Amusingly, the ACM considered the resulting
acrimony sufficiently harmful that it will (by policy) no longer
print an article taking so assertive a position against a coding
practice. In the ensuing decades, a large number of both serious
papers and parodies have borne titles of the form "X
considered Y". The structured-programming wars eventually blew
over with the realization that both sides were wrong, but use of
such titles has remained as a persistent minor in-joke (the
`considered silly' found at various places in this lexicon is
related).
--
Kevin Kevin.R.Boyce@gsfc.nasa.gov
What may appear to the faint-hearted as a limitless expanse of God-forsaken wilderness is in reality a golden opportunity for ourselves, and our children, and our children's children, and the generations a-comin' to carve a new life out of the American Indian.
--Firesign Theatre
+++++++++++++++++++++++++++
>From walkerj@math.scarolina.edu (James W. Walker)
Date: 26 Aug 1994 17:25:30 GMT
Organization: Dept. of Mathematics, Univ. of South Carolina
In article <33k3rp$b4v@search01.news.aol.com>, radixinc@aol.com (RadixInc)
wrote:
> There's a good article in "d e v e l o p," August 1992, called "Living In
> An Exceptional World" by Sean Parent. He proposes an elegant mechanism for
> handling exceptions with macros, including clean-up and recovery. His
> technique uses macros that resolve to gotos, but it keeps the source code
> clean. I've been using these macros for a year or so, and I haven't had to
> use an actual goto since. Check it out.
I use those macros too. However, I renamed his "nrequire" as "forbid". I
find it easier to read actual English words.
--
Jim Walker
+++++++++++++++++++++++++++
>From hanrek@cts.com (Mark Hanrek)
Date: 26 Aug 1994 18:31:38 GMT
Organization: The Information Workshop
If one is using a modern language, the "rule" to not use goto's is meaningless.
It was a rule meant to deter "spaghetti code", because it was so easy to
create a tangled web. With today's languages, we create messes of a
different kind.
The right thing to do, regardless, is to imitate the constructs and
structuring we find in good example source code.
Whether we code a "break", a "try/catch", or "goto", we are doing it
because it is the appropriate thing to do.
Hope this helps.
Mark Hanrek
+++++++++++++++++++++++++++
>From urge@mcl.ucsb.edu (Scott Bronson)
Date: 27 Aug 1994 23:27:35 GMT
Organization: University of California, Santa Barbara
In <Jaeger-2508942242470001@slip-1-21.ots.utexas.edu> Jaeger@fquest.com (Brian Stern) writes:
>The fact is that memerrors aren't fatal. there's nothing wrong with
>something like the following:
> h1 = NewHandle( 10 );
> h2 = NewHandle( 20 );
> p1 = NewPtr( 10 );
> p2 = NewPtr( 10 );
> if ( noErr != ( err = MemError() ) ) { /* do something */ }
Well, there's nothing wrong with *your* code, but there's a serious
flaw in this technique.
What about this:
h1 = NewHandle( 30 ), h2 = NewHandle( 10 );
If there are 26 bytes of memory free, h2 will be a vaild handle and
MemError() is going to report noErr because the last memory allocation
succeeded. However, h1 will be nil! If you do your memory allocations
from smallest to largest, you will probably be OK. However, heap
fragmentation can still cause some unexpected surprises when mixing
the allocation of pointers and handles.
So, even though this works, I hope that no programmers rely on it
unless they're sure they know EXACTLY what they're doing. Personally,
I shun it--too much analysis on noncritical parts of my code gives me
a bad case of programmer burnout.
- Scott (urge@mcl.mcl.ucsb.edu)
+++++++++++++++++++++++++++
>From bb@lightside.com (Bob Bradley)
Date: Sat, 27 Aug 1994 02:24:40 -0800
Organization: SS Software Inc.
In <Jaeger-2508942242470001@slip-1-21.ots.utexas.edu> Jaeger@fquest.com
(Brian Stern) writes:
>The fact is that memerrors aren't fatal. there's nothing wrong with
>something like the following:
> h1 = NewHandle( 10 );
> h2 = NewHandle( 20 );
> p1 = NewPtr( 10 );
> p2 = NewPtr( 10 );
> if ( noErr != ( err = MemError() ) ) { /* do something */ }
If you don't have enough memory for the first one, you're still going to
try all the others. I would check for both the handle not being NULL and
that MemError() did not return anything but, noErr after each call to
